![[アップデート] ECS Fargate でも AWS FIS のネットワーク障害系のアクションがサポートされるようになった…はずだったのだが、そのままでは動かなかったので無理やり動かした](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-6d4fdf3578638cab4e6e4655b3d692aa/15a803840d72679e6593006354d5766b/amazon-elastic-container-service)
[アップデート] ECS Fargate でも AWS FIS のネットワーク障害系のアクションがサポートされるようになった…はずだったのだが、そのままでは動かなかったので無理やり動かした
2024.12.26いわさです。
先週のアップデートになりますが、ECS Fargate で FIS のネックワーク障害系のアクションがサポートされました。
これどういうことかというと、2023 年の 6 月に ECS と EKS でネックワーク障害（パケットロス、レイテンシ増加など）を含むいくつかのアクションが追加されています。
しかし、その時点では追加アクションのうちの次の 4 つに関しては Fargate では未サポートな状態でした。これが今回のアップデートでサポートされるようになりました。
- aws:ecs:task-kill-process
- aws:ecs:task-network-blackhole-port
- aws:ecs:task-network-latency
- aws:ecs:task-network-packet-loss
英語版ドキュメントでは既に上記制限事項について削除済みですが、日本語ドキュメントではまだ確認が可能です。
実現方法ですが、2023 年のアップデートと同じで、SSM エージェントのサイドカーコンテナを使って障害注入アクションを SSM Run Command で実行する形です。
引用元：https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html
やってみたが...
細かい点は 1 年前のアップデートと同じなので割愛しますが、まず、適当な Web アプリのタスク定義に次のように SSM エージェントのサイドカーを追加します。
環境変数にマネージドロール名を指定するのを忘れないようにしましょう。
また、タスク定義のインフラ設定で次のように「フォールトインジェクション」設定を有効化します。
他にもネットワークモードが bridge 以外とか pidMode が task であることなどいくつか条件があるのですが、Fargate かつ Linux の場合であれば特に気をつけなくてもその前提を満たすはずです。
この時点でタスクに割り当てられたパブリック IP アドレスにアクセスしてみると次のようにレスポンスを取得出来ます。0.05 秒くらいでしょうか。
% curl -w "code: %{http_code}, speed: %{time_total}\n" -o /dev/null -s http://13.231.103.127/
code: 200, speed: 0.055141
% curl -w "code: %{http_code}, speed: %{time_total}\n" -o /dev/null -s http://13.231.103.127/
code: 200, speed: 0.061231
% curl -w "code: %{http_code}, speed: %{time_total}\n" -o /dev/null -s http://13.231.103.127/
code: 200, speed: 0.053228
続いて FIS の実験テンプレートを作成します。今回はaws:ecs:task-network-latencyを発生させます。
実験テンプレート側で意識する点としては、アクション設定の一番下にある「Use ECS fault injection endpoints」を有効化することです（デフォルトは無効）
これ、設定しないとどうなるかというと、Fargat 用の SSM ドキュメントが選択されずに次のように「Fargate ではサポートされてませんよ」というエラーが発生します。
Unable to run the action task-network-latency due to denied capability.
Network actions are not supported for Fargate tasks.
上記を有効化して SSM エージェントが正しく構成されていれば成功します。やってみましょう。
いけっ！
あれ...
SSM run document invocation with id c71ffce8-77d4-4d7f-b1b9-2ec6ae058895 has status FAILED.
Run Command の実行結果を確認してみましょう。確かに失敗しています。
無理やり動かしてみた
この障害アクションですが、「AWSFIS-Run-Network-Latency-ECS」という SSM ドキュメントが実行されます。
ログから推察するにおそらく次の systemctl あたりで失敗しています。
コンテナイメージを変更してみたのですが私に力ではこのあたりを通すイメージを作成することは出来ませんでした。
ただ上記コマンドは依存パッケージのインストールフェーズでのみ行われているので、ここをスキップすればワンチャンあるかもしれない。
次のように実験テンプレート側で依存パッケージのインストールオプションを無効化してみました。
このオプションを無効化すると、SSM ドキュメント上のインストールステップが実行されず、もし必要パッケージがインストールされていない場合はエラーとなります。
早速試してみたのですが何度インストールしてみてもなぜかインストールされていないと判断されてしまっていました。
どうやらチェック部分のcommand -v curl-minimalが良く無さそうです。curlをチェックすべきなんじゃないだろうか。
ということで、FIS での実験テンプレート前に独自のドキュメントでインストールと curl-minimal のシンボリックリンクを作成しておきました。こんなやつです。
上記実行後に実験を開始してみると...成功しました！
上記 Running 中のレスポンスを確認してみると次のようにレイテンシが増加していることも確認出来ました。3,000ミリ秒増やしたつもりだったのですが、6,000ミリ秒増えていそう...。
% curl -w "code: %{http_code}, speed: %{time_total}\n" -o /dev/null -s http://13.231.103.127/
code: 200, speed: 6.059521
% curl -w "code: %{http_code}, speed: %{time_total}\n" -o /dev/null -s http://13.231.103.127/
code: 200, speed: 6.062007
% curl -w "code: %{http_code}, speed: %{time_total}\n" -o /dev/null -s http://13.231.103.127/
code: 200, speed: 6.053852
さいごに
本日は ECS Fargate でも AWS FIS のネットワーク障害系のアクションがサポートされるようになったので、試してみました。
無事（？）動かすことが出来ました。後半部分は無理やり動かすために実行した手順なので無視してください。
SSM ドキュメントで気になった点はフィードバックしておきたいと思います。すぐに問題なく動くように更新される気がします。
![[レポート] Optimize data processing with built-in AWS Step Functions featuresに参加しました #AWSreInvent #API207](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
